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We study an assignment system of intersection types for a lambda-calculus with records and a record- 
merge operator, where types are preserved both under subject reduction and expansion. The calcu¬ 
lus is expressive enough to naturally represent mixins as functions over recursively defined classes, 
whose fixed points, the objects, are recursive records. In spite of the double recursion that is in¬ 
volved in their definition, classes and mixins can be meaningfully typed without resorting to neither 
recursive nor F-bounded polymorphic types. 

We then adapt mixin construct and composition to Java and C#, relying solely on existing features 
in such a way that the resulting code remains typable in the respective type systems. We exhibit some 
example code, and study its typings in the intersection type system via interpretation into the lambda- 
calculus with records we have proposed. 


1 Introduction 

Starting with Cardelli’s pioneering work fTTll . various typed lambda calculi extended with records have 
been thoroughly studied to model sophisticated features of object-oriented programming languages, like 
recursive objects and classes, object extension, method overriding and inheritance (see e.g. EM El). 

Here we focus on object composition based on mixins, a study initiated in Q ® and based on the 
recursive record model and F-bounded polymorphic types flOlflZ l. In the object-oriented paradigm, mix¬ 
ins have been introduced as an alternative construct w.r.t. class inheritance to avoid semantic ambiguities 
caused by multiple inheritance. Together with abstract classes and traits, mixins can be considered as an 
advanced construct to obtain flexible implementation of module libraries and to enhance code reusability; 
many popular programming languages miss native support for mixins, but they are object of intensive 
study and research (e.g. as si). Scala supports mixins, which recently have been used to model feature 
oriented programming lfl9l . Dynamic languages, such as JavaScript, offer multiple ways to compensate 
for the lack of mixins l20l . 

In ll22l a new technique for synthesizing programs from components has been based on combinatory 
logic and intersection types. Aiming at a future extension of the approach to Object-Oriented (00) 
libraries, we study an assignment system of intersection types for a A-calculus with records and a record- 
merge operator, building over and extending the systems proposed in lfT4l !3, 231. 

In section 2, we propose a type-free A-calculus with record and record-merge operator, and define 
a Curry-style type assignment system. Such a system is polymorphic in the sense that any term has 
infinitely many types, including the trivial type co. In doing that, we look for an extension of the system 
in 0, and in particular we expect that typing is invariant under subject reduction and expansion. In 
this respect the main difficulty consists in the typing of Bracha-Cook’s merge operator, which embodies 


Jakob Rehof (Ed.): Intersection Types and Related Systems (ITR! 
EPTCS 177, 2015, pp. 79-[93] doi: 10.4204/EPTCS. 177.7 


J. Bessai, A.Dudenhefner,B.Dtidder,T. Chen, U. de’Liguoro 
his work is licensed under the 


Creative Commons Attribution License. 



80 


Classes and Mixins with Intersection Types 


at the same time record extension and field overriding. To solve such a problem we distinguish among 
ordinary A-terms and record terms, allowing just record terms to be merged to arbitrary terms. In section 
3, we then study the typings in our system of the encoding of classes and mixins into the A-calculus 
proposed in lfl2l l8l. identifying a subset of intersection types that can be seen as meaningful types for 
such entities. We then consider (Section 3) the problem of using the proposed system in the case of 
the actual programming languages Java and C#, that do not embody mixins in their syntax; nevertheless 
programs that typecheck w.r.t. the type system of the respecitive programming language can be seen 
as the product of the fully applied mixin compositions. We face these challenges by using delegation 
instead of inheritance. This gives rise to a design pattern that can be interpreted in the A-calculus with 
records, such that the typings we have devised for classes and mixins in the theoretical model apply to 
actual programming languages. 

This work evolves from the contributions j5j[l5! to the workshop ITRS’ 14. Joining the contributions 
from both previous papers, this work contributes a way to model classes and mixins typable in the 
intersection type system. The flexibility of this type system allows to augment types by semantic features, 
required for a future extension to automatically synthesize 00 code Furthermore we present a 
correspondence between the model and actual programming languages. 

The authors have been supported by the research grant of the European Union ICT COST Action 
(IC1201): Behavioural Types for Reliable Large-Scale Software Systems (BETTY). 

2 Intersection types for a A-calculus with records and merge 

We consider a type-free A-calculus of records equipped with a merge operator. The syntax of Kr is 
defined by the following grammar: 

Term: M,N:: = x\ (A x.M) | ( MN ) | R | ( M.a ) | (M®R) Record: R ::= (a,- = M, \ i £ 7) 

where x £ Var and a £ Label range over denumerably many variables and labels respectively. In R = 
(a, = Mi | i El) (writing = for syntactic identity) the set I is finite; we define lbl(R) = {a,- | i £ /} to 
denote the set of labels of R and we use the abbreviation a = M £ R for a = a,- & M = M,- for some i £ I. 

Definition 2.1 (Ar Reduction) 


03) 

(. XxM)N - 

-> M{N/x} 


( rsel ) 

(ai = Mj i £ 7) .aj — 

M i 

if j e i 

(©) (fl; = Mj 

i £ /) © (uj = Nj j £ J) — 

<T 

ii 

ii 

t 

i £ I\J j j £ J) 


The last reduction makes it apparent that ® is record merge from |[7j, which is written <— r , and the 
analogous operator in |[8]|, although in our notation M © R the record arguments are listed in the opposite 
order than in [HO, namely whenever M reduces to a record R' the fields in R prevail over those in R' having 
the same labels. 

Definition 2.2 (Intersection types for Ar) 

<t,t ::= a | t\ co \ a -o- t | an t | (a: a). 

Here a ranges over a countable set of type variables, t are type constants for ground types, e.g. int, bool, 
or for (atomic) abstract properties, like Evenlnt or CelsiusDeg; co is the universal type; a —> T and o Pi T 
are the arrow and the intersection types respectively. Finally {a : a) is the type of records having a label 
a with value of type a. 
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Definition 2.3 (Type Inclusion) Over types we consider the preorder < extending EATS axioms (see 
e.g. |]2), Def. 3.3.1) by the last two axioms: 


<7 < CO, CO<CO—>CO, C5TlT<a, 
<7 < Z\ & a < t 2 =>■ o < Ti n T2, 
a < t =A (a : a) < (a : t), 


anr<T, (aTi)n (a-> t 2 ) < a —^ ti n t 2 , 

<J 2 < C7i & Ti < T 2 =>• G\ —> Ti < a 2 —» t 2 , 

(a : a) n (a : t) < (a : ant). 


Note that we have (a : (?) n (a : t) = (a : a n f) where = is the symmetric closure of <. Also we have 
(a : co) 7 ^ (0 for any a. 


Definition 2.4 (Type Assignment) The assignment system adds the rules (sc/), (rec), (©/), (ffi r ) to the 
intersection type assignment |[H (but with the < relation from Def. |2.3|): 


x : <7 e T 

r\~ x: a 


(Ax) 


T,x : a h M : z 
T h Xx.M : a —> t 


(-> 7 ) 


rhM : (7 —)• T rh A : (7 

r h MA : T 


•A) 


-(<») 

fhM:® 


rbM:a n-M:t 

-(n/) 

Tb M: ant 


r\- M : (7 <7 < T 

FhM : T 


(<) 


T b M : (a : a) 

- {sel) 

T b M.a : a 


rb M:a a = M€R 
r b R: (a : ct) 


(.rec ) 


rb/?: (n: a) 

T b M © R : {a : a) 

Record types express just partial information about the fields in a record, as it is apparent from rule (rec); 
typings of more than one field in a record are obtained by means of intersection (see below). Rule {sel) 
is the expected one. Rules (©/) and (® r ) are not symmetric because of the restriction a 0 lbl{R) in the 
last rule. Such a restriction is essential for the soundnes of the system, in particular for subject reduction 
to hold. E.g. we have ( a = M) © {a = A) — > {a = A); now supposing that M : a, A : x where a/t 
and that a cannot be assigned to A, without the restriction we could type {a = M) © {a = A) by {a : a) 
and even by {a : a) n {a : x) = {a : <J n t), but we couldn’t type (a = A) by neither of these types. 

Let us abbreviate {ai : a, | i e I) = C\i£i{ a i '■ ©} where we assume the a,- to be pairwise distinct. By 
abusing terminology we call it a record type. Then the following rule is admissible: 

Oj <rj V./ 6/C/ 

(a,-: <7, | i El) < {aj : T/ | j'G/) 

which is record subtyping in width and depth. Further we have the following admissible typing rules: 

r b Ai: <7/ MiElCJ r b M : (a,-: a, | f e /) TbS: (a ; -: Tj | ; e /) 


r b M : (a : o) a ^ lbl{R) 
T b M © R : {a : a) 


(©/) 


T b (a,- = A,- | i EJ) : (a;: < 7 , | i € /) 


TbM ® ft: (a,': <7;, ay : Ty | i S 7\T, j € 7) 
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We exemplify the typings of functions from records to records, that are at the earth of the encoding of 
mixins. Let Mr. = Ax.(x © 7?;), where R\ = (a = Ai), 7?2 = (b = N 2 ) and Rj = (a = A 3 }. For simplicity 
let us assume x //v(7?,-) for i = 1,2,3; then 

T,x : co\- N 1 : CTi 

T,x : co F x : co T,x : co F (a = Ai) : (a : <7i) 

T,x : (0 F x © (a = N\) : (a : <7i) 
r F Mr j = Ax.(x © (a = N\}) : to —> (a : (Ti) 

and also 

r,x : (b : a?) Fx: (b : 02 ) b / lbl((a = Ai)) 

r,x : (b : 02) F x © (a = N\) : (b : 02) 

r F Mr { = Ax.(x ffi (a = Ai)) : (ft : 02) —> (b : 02) 
therefore by co ^ (a : Gi) < (b : a?) —> (a : G\) we have 

r F M Rl : ((b : <r 2 ) —>• (a : <7i)) fl {{b : <r 2 ) —>• (fe : <t 2 )) 

that is r F M« I : (ft : <72) —>• (fl : Ci,ft : 02 ). Similarly for assuming that T F AS : (72 we have 
r F Ms, : ft) —>• (ft : CT 2 ) so that 

T F Mr 2 : co —>■ (ft : 02) r F M Sl : (ft : a 2 ) —>• (a : cti, ft : a 2 ) 

T F Ms, oMs, : w —> (a : G\ ,ft : a 2 ) 

where MoN = BMN =p Xx.M(Nx). If T F N\ : ai, T FIV 3 : G 3 but T\/Ni : (73 we have 
T F Ms, : CO —> (a : <7 3 ) and T F M r<] : co ->• (a : <7i) < (a : 03) ->• (a : <7i) 
so that r F Ms[ oMs, : w —>• (a : Ci) but T l/Ms, oMs, : w —)■ (a : CT3). 

Let M = IV be the convertibility relation generated by —>; then we can pi'ovcQ 

Theorem 2.5 (Type Invariance for As) For any M,N £ As, 

F\~M: o&M = N =© T F A : a. 

Remark 2.6 By definition © x 0 As and hence Ax.(7? © x) 0 As- If we admit record terms of the 
shape 7? © x then their typing would be highly problematic. The problem is that to apply rule (©/) when 
typing R ffi x we have to extend Ibl to variables. If we set /ft/(x) = 0 the side condition a 0 0 of rule (©/) 
is always satisfied, and we could derive for R ffi x all the types of 7?; hence for any a: 

T,x : G F R : (a : t) a^L lbl(x) = 0 

T.x : G F 7? ffi x : (a : t) 

T F Ax. (R ffi x): <7 -»• (a : t) 

Let G = (a : p) and N such that FFiV: p and F\f N : T. Then T F (Ax. (7? ffi x))(a = N) : (a: t), while 
r 1/7? ffi (a = N) : (a : t), contradicting subject reduction. 

One could think to change the definition of /ft/(x) to Ibl'(x) = Label, since the variable x can be 
replaced by /3-reduction with any record 7? ; , whose set of labels we cannot predict. This time the side 
condition a / Label never holds true, so that (Ax.(7? ffi x))(a = A) would have less types than 7? ffi (a = 
A), breaking subject expansion. 

'Proof available in the appendix of http://www-seal.cs.tu-dortmund.de/seal/downloads/papers/ 
paper-ITRS2014-postproceedings.pdf 
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3 Class and mixin interpretation and typings 

Here we study the typings of the interpretations of classes and mixins based on the recursive-record 
model, following (SJ. We proceed by steps, considering non-recursive classes and mixins first; then we 
move to the respective recursive versions. 

Non-recursive classes. Under recursive record interpretations a non-recursive class is a function: 

C = Ax A self, (a i = M\,... ,a^ = Mk) 

where x are the parameters for the initial values (the state). Class C is pre-instantiated when applied to a 
tuple of values v of the same length as x: C v = A self, (a i = M\ [v/x],... = Mk[v/x\). Objects, or class 

instances, are fixed points of pre-instantiated classes: 

0 = Y(C v) = (oi = M\[v/x, O/self],... =Mk[v/x, O/self]) where Y = A/.(Ax/(xx))(Ax/(xx)) is 
Cuiry’s fixed point combinator and equality is conversion. Then sending a message a to the object O is 
defined as record selection: O <= a = O.a. Indeed, for i G {1,... 

O <= a, = ((oi =Mi[v/x, O/self],... ,ak = [v/x, 0/self]) ).a,- = Mj[v/x, 0 / self]. 

For example let us consider the class: Point = Ax Aself.(X = x, get = self.X), such that X is the field 
holding the position of a one dimensional point (the object state), get returns the position of its point. 
Looking at the typings of Point(3) = Aself.(X = 3, get = self.X), we have: 

self: (0 P 3 : int 

self :fflh{X = 3, get = self.X) : (X : int) 

P Aself.(X = 3, get = self.X) : co —* (X : int) 

but also, setting 0 \ = (X : int): 


self: Ci h 3 : int self: C7i P self.X : int 
self: CTi P (X = 3, get = self.X) : (X : int, get: int) 

P Aself.(X = 3, get = self.X) : 0 \ —» (X : int, get: int) 

so that, putting 02 = (X : int, get: int), we have 

Point: int —> (co —> <7i) Cl (ci —> 02 ) 

and hence Point(3) :(©—>• <7i) Cl (<7i —> 02 ). It is folklore (see e.g. 1T61 . Sec. 2) that with intersection 
types we can type Y = A/.(Ax. f(xx))( Ax. /(xx)) by (w —> Ti) n (ti —> T 2 ) Cl • • • Cl (t„_ 1 —> t n ) —*■ z n 
for any n and Z \,..., f„; hence we conclude that 

point = Y(Point(3)) = (X = 3, get = point.X) : (X : int, get: int) 

and therefore both (point -4= X) : int and (point <^= get) : int. Observe that neither typings of the class 
Point nor of the object point are recursive types. 
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Let t be a vector of ground types and <7i,..., <7„ be record types, i.e. the types of class instances ; then 
by generalizing from the above example we define: 

n— 1 

Non-recursive class type: k ::= t —>• (co —> CTi) n P) (ay -> a,- + i). 

1=1 

Note that K < t -* (a,- —> a,+i) for any i = 1 7 ... ,n — 1, but this typing would be not enough for typing 
objects obtained as fixed points of pre-instantiated classes. 

Non-recursive mixins are functions from non-recursive classes to non-recursive classes: 

M = Asuper Ax Aself. Y(supery) 0 {a\ = Mi,...,a* = AT*), y C£ 

Note that both self and super may occur free in the Mj. Let’s consider the example of a mixin adding a 
second dimension to one dimension points of class Point: 

Point2D = Asuper Ax Ay Aself. Y(superx) © (Y = y, get = (c.X, self. Y)} 

The apparently equivalent term Asuper Ax Ay Aself. Y(super x) © (Y = y, get = (x,self.Y)) is coarser 
than Point2D, because it ignores the usage of the state variable x by the superclass super, which is a 
parameter. By simple computations we obtain: 

Point2D(Point) = Ax Ay Aself. Y(Point x) © (Y = y, get = ((Y(Point x)).X,self.Y)) 

= Ax Ay Aself. (X = x, get = ...} © (Y = y, get = (x, self.Y)) 

= Ax Ay Aself. (X = x, Y = y, get = (x, self.Y)} 

By adding product types (for exemplification purposes) we easily derive that Point2D(Point) has type: 

int —)• int —> (co —> (X : int, Y : int)) n ((X : int, Y : int) —>■ (X : int, Y : int, get: int x int)) 

which is a non-recursive class type. In general we conclude that a non-recursive mixin has type K\ —y Ki, 
where Xi, Ki arc non-recursive class types. 

Recursive classes and mixins. Recursive classes and mixins are necessary whenever the resulting class 
is used to generate a new object of the same class (see the example with movable points below). Recursive 
classes have an extra parameter myClass: 

C' = AmyClass Ax Aself.(aj = M\,... ,ak = M*). 

The fixed point of a recursive class is a class; so to instantiate a recursive class to an object, a double 
fixed point is needed: O' = Y((YC / )v). Because of this, types of recursive classes have the shape: 

n— 1 

Recursive class type: k' ::= (co -y JCi) n n (Kj-> JQ+i) 

i= 1 

where fC]..... Ky arc non-recursive class types. We observe that all x, begin by the same the same t and 
include record types a i,i,..., that can be choosed so that > Oij+ 1 , to form a descending chain. 

The object O' is a record, that can be merged in a mixin with a record A(super) (myClass)(x) (self) = 
(oi = M \.... ,a^ = Mk) of added/overridden members: 

M' = Asuper AmyClass Ax Aself. Y((Ysuper) y) © A(super)(myClass)(x)(self), y C x. 
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As an example, consider the following mixin: 

Movable = Asuper AmyClass Ax Aself. Y((Ysuper)x) © (move = A dx. Y((Y myClass) (self.X + dx))) 

Now let RecPoint = AmyClass. Point be a (vacuously) recursive version of Point, and consider the 
object movable = Y (Y (Movable RecPoint) 3). Then for example we have: 

(movable -t= move)(4) 

= ((Y(Y RecPoint 3) 0 

(move = A dx. Y(Y (Movable RecPoint) (movable.X + dx)))) -q= move)(4) 

= ((X = 3, get = ..., move = A dx. Y(Y (Movable RecPoint) (movable.X + r/x))).move)(4) 

= Y(Y(Movable RecPoint) (movable.X + 4)) 

= Y((Y(Movable RecPoint)) (3+ 4)) since movable.X = 3 

= (X = 7, get = ..., move = ...). 

To see a possible typing of Movable, let jq = int —^ (co —> cq) n (C\ —> <7 2 ), which we know to be a 
type of the class Point; then co —>• jq is a type of RecPoint. Now 

x : int h Y RecPoint: rq x : int P x : int 

x : int h Y RecPoint x : (ft) —> <7i) n ( 0 \ —> c 2 ) 

x : int P Y(Y RecPoint x) : g 2 = (X : int, get: int) 

and therefore, with X and get being different from move, and super being bound to RecPoint in movable 
we have: 

super : co —> jq, x : int h Y(Y super x) © (move = A dx. Y((Y myClass) (self.X + dx)) : o 2 . 

Let IP = {super : co —> jq, myClass : co —> tq,x : int, self: C 7 i}; then, since we have: 

T 2 ,dx : int P self.X : int T 2 ,dx: int P dx : int 
T 2 ,dx : int P self.X + r/x : int 

it follows that: 

r 2 ,dx : int h Y myClass : Ki = int —> (co —> CTj) Cl (tJi —> c 2 ) 

T 2 ,dx : int h (Y myClass) (self.X + dx) : (co —> < 7 i) Cl (<Ti — >- cr 2 ) 
r 2 ,dx : int h Y((Y myClass) (self.X + dx)) : a 2 
r 2 ,P Xdx. Y((Y myClass) (self.X + dx)) : int —> a 2 

and we conclude that: 

r 2 P Y(Y super x) © (move = A dx. Y((Y myClass) (self.X + dx)) : t7 2 n (move : int —> <J 2 ), 
so that by taking tc 2 = int —> (<r 2 Cl (move : int —> <r 2 )) we can derive the typing: 

Movable : (co —> ffi) ->• (co ->■ fCi) n (ffi —> k 2 ), 
that is of the form fc( —> k( where >cj, id, arc recursive class types. 
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Mixin composition. Since mixins are just functions from classes to classes, the natural way to compose 
them is by functional composition. To make it easier to compare with definitions in 13, we compute 
their composition up to conversion. For i = 1,2 let 

= Asuper,- Aself,-. Y(super,-) 0 A,-(super,)(self,) 

be a pair of (non-recursive) mixins, where A,-(super,)(self,) is the record of added/overridden methods, 
and we forget about the state for simplicity. Then, for a suitably non-recursive class C we have: 

{MioM\){C) = M 2 (Mi(C)) 

= A self?. Y(Mi(C)) © A 2 {M\ (C)))(self 2 ) 

= Aself 2 .M 1 (C)(Y(Mi(C))) 0 A 2 (M 1 (C)))(self 2 ) 

= A self?. Y(C) © Ai(C)(Y(M!(C))) 0 A 2 (M 1 (C)))(self 2 ) 


so that we obtain: 

M 2 oM| = Asuper Aself. Y(super) 0 Ai(super)(Mi (super)) 0 A 2 (Mj (super))(self), 

which is essentially Bracha’s wrapper composition in § 5.2 of Q. In the slightly more complex case of 
recursive mixins (without the state): 

Mj = Asuper,- AmyClass,- Aself,-. Y(Ysuper,-) 0 A((super,-)(myClass,-)(self,-) 

composition M ' 2 o M\ is given by: 

Asuper AmyClass Aself. Y(Ysuper) 0 

A , 1 (Y(M , 1 super)) (Y(Y(M(super))) 0 A 2 (Mjsuper)(myClass)(self). 

In spite of their complex shape, recursive mixins have arrow types with recursive-record types as both 
left and right-hand sides. It follows that their composition into a linearized form ( 8 l is just functional 
composition, that combined with the subtyping relation can be typed by: 

h M[ : k[ —> Kf 2 h M ' 2 : fcj —> k 2 < k ' 3 

\-M' 2 oM[ : k[ —> 

Subtype properties. In general a mixin abstraction 

Asuper.AmyClass.A.r.Aself.(Y((Ysuper) y)) 0 A(super)(myClass)(.r)(self), y Qx (1) 

has a type of the form fc( —y k 2 , and the instances of classes tcj have record-type a,- for i G { 1 , 2 }, say, 
so that a? is the type of body of the abstraction (jT|). Inequation a? < , where is the type of 

A(super)(myClass)(jc)(self), holds as a direct consequence of the rule ( 0 r ). However, a? < ai is only 
satisfied, if no label of the class super was overwritten. Therefore, our mixin encoding is more powerful 
Ell than the existing approach of abstract base class inheritance. Analogously to Cook et al. llT2ll . we 
pinpoint the distinction between mixin application and subtyping. 
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4 Mixin Features In Existing Programming Languages 

In this section we implement mixins, presented in the lambda-calculus with records and a record-merge 
operator, using standard features of modern Object Oriented (00) languages. The correspondence 
between calculus and programs is exemplified, in particular the correspondence between typability in 
lambda calculus and typability in Java like type systems. 

Applying the theoretical model to a practically useful programming language, we face several chal¬ 
lenges. First, mixins are not native concepts in mainstream 00 languages. Code-generation and the 
regularity of a design pattern exploiting existing features, namely delegation, abstract classes, inheri¬ 
tance and generics, can compensate for this deficit. In Java-like languages inheritance alone is incapable 
to implement all mixin features due to restrictions of overriding (cf. Section[3]) and overloading methods. 
Second, real languages use references and side effects which are not present in the presented calculus. 
To approximate this, state is modeled functionally in the calculus, while access to state is restricted only 
to get and set methods in the real language, e.g. Java. We consider the following subset of the presented 
calculus: 

1. We consider recursive classes C with an aggregated state x: 

C = AmyClass.Ax.Aself.(ai = M\,... = A/*) 

2. We consider recursive mixins M that map recursive classes to recursive classes and do no add state: 
M = Asuper.AmyClass.Ax.Aself. Y((Y super)*) © {a\=M\,...,a.k = Mk) 

3. State, passed as variable x, is directly accessed only by get and set methods. 

4. Each method that modifies the state of the underlying object returns a tuple (newState, result), 
where newState is the new state of the object (updated value to pass as x, not the updated object) 
after the method call and result is the result of the method call. 

5. Each class and each mixin contains the special method new = Ax / .Y(myClassx / ) 

In addition the above restrictions, we capture common subterms and decompose tuples using the 
“let ... in” construction, which only serves as syntactic sugar and disallows any recursive definition. 

Restriction [2] is used to separate the concerns of storing data in classes and add/replace methods in 
mixins. Additionally, restrictions [2] and [4] are used for seamless delegation of methods. Restrictions [4] 
and[5]are used to implement functional state update. As an example, we model the invocation of method 
a in an object o that updates the state of o and returns a result r by 

let ( x,r)=o.a in (let o' = o.new(x) in ...) 

After the invocation of a, the variable o' is bound to a new instance of the underlying class with an 
updated state. Note that the underlying class of o is not expressed explicitly. 

There arc various more advanced approaches for modeling state in typed A-calculi, e.g. reference 
cells fl3l or Monads ifTTil . The presented version using get and set methods, is chosen for simplicity and 
compatibility to the type system. 

The remaining section describes the relationship between mixins in the presented calculus and well 
typed code implementing mixin features. This relationship is a necessary step for a future extension of 
manual mixin application to provably reliable automatic synthesis. In particular, the following corre¬ 
spondences are demonstrated: 

• Recursive classes in the presented calculus and classes in 00 languages. 

• A-terms (records of updated methods) of recursive mixins and design pattern based A-definitions. 

• Mixin application and delegation based composition of classes and mixin implementations. 


Classes and Mixins with Intersection Types 


Class Point 
State 
x: int 
Definitions 
get : Unit —> int 
get() = { self.x } 
set : int —y Unit 
set(x 5 ) = { self.x := x’ } 
shift : Unit -> Unit 

shift () = { self . set ( self . get () + 1) } 

(a) Pseudo-code of class Point (b) UML diagram of class Point 

Figure 1: Pseudo-code and UML diagram of class Point 


Point 


x : int 


+ Point(x : int) 

+ get() : int 
+ set(x : int) : void 
+ shift() : void 


To illustrate those correspondences we use pseudo-code as an intermediate layer between calculus 
and real code. For brevity, implementation code is illustrated via UML diagrams. Example implementa¬ 
tions in Java and C# are available in online 0 

We extend the model-theoretic class Point from Section[2]to the new class Point for interpreting the 
stateful Java/C# class Point, by adding the methods set and shift. The pseudo-code implementation as 
well as an UML representation of the Java/C# implementation of Poi nt are shown in Figure[l] Respecting 
above restrictions to the presented calculus, we represent Point by the following term: 

Point = AmyClass.Ax.Aself. 

(get = x,set = ()), shift = self.set(self.get+ l),new = Ax / .Y(myClassx / )) 

Note that interaction with the state x of Point happens via the get and set. We derive a type )Cp oint out 
of the many types of Point using the following pattern: 

(get: int, set: int — > (int x Unit), shift: 0 ). new : int — > co) 

(get: int, set : int —> ( int x Unit), shift: ( int x Unit), new : int —> ft)) 

(get : int, set : int —> (int x Unit), shift : (int x Unit),new : int —> a 2 Point ) 

int ->(©-»• ar° int ) n (ar° int -> a 2 Point ) 

int ->(©->• ar° int ) n (ar° int -> a 2 Point ) n (a 2 Point ->• a 3 Point ) 

(m ->■ tc 1 Point ) n ()q Point -> fc Point ) 

The type a Point describes an instance of Point after the double fixed point construction fixing myClass 
and self. The type cxf oint describes the intermediate term resulting from the first fixed point construction 
that fixes myClass. 

Next, we define two mixins Movable and SetAdapter presented in Figure [2] Movable requires the 
get and set methods to define the move method, moving the current point by dx. SetAdapter redefines 
the set method to handle an instance of Point as input. Note that super is used to access methods of the 
corresponding mixin argument. 

J http://www-seal.cs.tu-dortmund.de/seal/downloads/research/ITRS2014PostProc.zip 
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Mixin Movable (C) 

Requirements 
get : Unit —> int 
set : int —> Unit 
Definitions 
move: int —y Unit 
move(dx) = 

{ super . set ( super . get () + dx) } 



(a) Pseudo-code of mixin Movable 


Mixin Set Adapter (C) 
Requirements 
set : int —> Unit 
Definitions 
set : Point -» Unit 
set(p) = 

{ super.set(p.get()) } 
(c) Pseudo-code of mixin SetAdapter 


(b) UML Diagram of mixin Movable 



(d) UML Diagram of mixin SetAdapter 


Figure 2: Pseudo-code and UML diagrams of mixins Movable and SetAdapter 


Respecting above restrictions to the presented calculus, we represent Movable by the following term: 

Movable = Asuper.AmyClass.A.r.Aself. 

let c = Y((Ysuper)x) in 

let A = (move = Xdx. c.set(c.get + dx),new = Ax , .Y(myClass.r / )} in 
c © A 

We derive a type K^ oint —> (C|^ ovab | e out of the many types of Movable using the following pattern: 

0 .Movable = (g e t; int,set: int -> (int x Unit), shift: ( int x Unit)) 

FI (move : int —> ( int X Unit),new : int —> co) 

^Movable = ^g e t ; i n ( se t; int -» (int x Unit), shift: (int x Unit)) 
n (move : int —> ( int X Unit), new : int —> ( j 1 Movable ) 

V -v-' 

type tyMovable i nc [ uce( j by the mixin description 
..Movable • . . /., , -.Movable-, 

K i =mt —> (CO —> Ctj j 

..Movable ■ , , /,, , _Movable\^/-.Movable , -.Movablet 

K 2 =mt((0 1 > <7 2 ) 

-J _/,., , ..Movable-, /..Movable , ..Movable-, 

^Movable — V® ^ M J'HM “A K 2 ) 



















































90 


Classes and Mixins with Intersection Types 


Note that the type of move : int —y (,int x Unit) follows a uniform type structure not bound to the 
mixin Movable and, therefore, allows for seamless delegation. 

Similarly, SetAdapter is represented by the following term and is typed by Nviovabie ^SetAdapter- 

SetAdapter = Asuper.AmyClass.Ax.Aself. 

let c = Y((Ysuper)*) in 

let A = (set = Xp.c.set(p.get),new = A* / .Y(myClass* / )) in 
c © A 


^.SetAdapter 


^SetAdapter 

°2 


^.SetAdapter 


SetAdapter 

*1 

SetAdapter 

K 2 

SetAdapter 

*3 

''•SetAdapter 


=(get: inf, shift: ( int x Unit), move : int —> (int x Unit)) 
n (set: (get: int) —> (int x Unit), new : int —> to) 

=(get: int, shift: (int x Unit), move : int —> (int x Unit)) 
n (set: (get: int) —> (int x Unit), new : int —> CJ -S etAda P ter ^ 
=(get: int, shift: (int x Unit) , move : int —> (int x Unit)) 
n (set: (get: int) —> (int x Unit), new : int —> CJ -S etAda P ter j > 


type (AetAdapter j [K | utec ] p,y L p e mixin description 


—int 
=int 
=int - 
= ((0 


( 0 ) 

(® 

(® 


SetAdapter 
7 1 

SetAdapter 
7 1 

SetAdapterx 

7 1 J 


) 

)n(a 


n (a 


SetAdapter 

1 

SetAdapter 

1 


SetAdapter \ 


SetAdapterx 


n(a. 


SetAdapter 


SetAdapterx 




SetAdapter^ 
1 ) 


n(«r 


SetAdapter 


SetAdapter 


)n(>c 


SetAdapter 

2 


K 


SetAdapter \ 


We encode A-terms in the implementation. Each A-term is represented by an abstract class extending 
the class Delta, which is available in an utility library. A-term representations are parameterized over 
a requirement interface type. This type is used for the library method getSuper, which provides the 
instance with which the A implementation will be merged. This instance can be guaranteed to be at least 
of the required interface type. Required interface types may be declared for each A (e.g. HasGetSet). 
They arc interfaces which, for reasons of structural regularity, extend the EmptyRequirement interface, 
also available in the utility library. A-term representations remain parametric over the type of the term 
they are merged with in order to allow getSuper to return an instance of that type, rather than just 
an instance of the requirement interface type. This is necessary to reuse getSuper for delegation of 
methods propagated after mixin application, without mentioning them in the requirement interface. 

Figure [4] shows the implemented result of applying Movable to Point and (below the dashed line) 
the application of SetAdapter to the previous result. First, MovablePoint is obtained by creating a 
new class that inherits from Movable. It thereby satisfies a j ) /[lxm < a^ lxin . Internally, MovablePoint 
delegates to the methods of a PointHasGetSet instance provided by the getSuper method inherited 
from Delta. Class PointHasGetSet extends Point and implements the requirement interface. The 
introduction of a new class is necessary in languages not supporting structural subtyping. Structurally 
Point < HasGetSet does hold, but in a nominal type system lfl2l subtype relationships have to be stated 
explicitly. The class MovablePoint propagates the non overwritten methods of Point, e.g. shift. Note 
that shift is not part of the requirement interface, but available since the type parameter of Movable is 
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let C = (SetAdapteroMovable)(Point) in 

pi := new Set Adapter ( Movable ( Point ))( 1 ) 

let pi = Y((YC) 1) in 

p2 := new Point (2) 

let p2 = Y((Y Point)!) in 

pi.set(p2) 

let (x,r) = pl.set(pl) in 


let pi' = pl.new(x) in 

p 1 . move ( 1 ) 

let (x',r r ) = pi'.move(l) in 


let pi” = pi'.new(x!) in 

pi.get() 

pi”.get () 


(a) Implementation pseudo-code (b) A^-calculus 

Figure 3: Instantiation and usage of Mixins 


bound to PointHasGetSet. Similarly, SetAdapterMovablePoint extends SetAdapter and delegates 
to MovablePointHasSet, which connects HasSet and MovablePoint. 

The UML diagram reveals the very regular nature of mixin application, which in a practical setting 
can be automated, s.t. blue classes in the diagram are synthesized by a code generator and do not have to 
be implemented by hand. Code generation corresponds to Ar reduction, performing the merge operation 
© on the super argument. In the case of Java and C# it is to be performed outside of the implementation 
language, because the creation of new named classes is not a native language feature. 

We compare the usage of the pseudo-code implementation and calculus description in the example 

shown in Figures [3a] and 3b Implementations in Java and C# are also available online and almost 

identical to the pseudo-code implementation. The main differences between the pseudo-code and the 

Ar version are the initial class instantiation and the different styles of passing state. In 00 languages 

class instantiation is performed by the built-in operator new. In A r we model new using the fixpoint 

operator Y respectively (cf. Section[3]). Passing state functionally requires explicit instantiation of copies 

of pi with an updated state (lines 5 and 7). Observe that in pi.set (line 4) is the new set method, 

however, pi.move (line 6 ) uses the old set method, which is the required behavior. Therefore, the final 

SetAdapter 


SetAdapter 


are a 


result produced by both implementations (line 8 ) is 3 : int. Observing that o 
necessary for the twofold state update of pi, we derive F pi : rrf’ etAda pter using the following derivation 
for (SetAdapter o Movable)(Point): 


P Movable ! K*point — v tq 


j 

Movable 


P SetAdapter : < 


Movable ^ ^SetAdapter 


P SetAdaptero Movable : K^ oint -A SetAdapter 


P Point: rep 


Point 


P (SetAdaptero Movable)(Point) : SetAdapter 
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Classes and Mixins with Intersection Types 



Figure 4: UML Diagram for synthesized code. The dotted line separates Movable(Point) from 
SetAdapter(Movable(Point)) 

5 Conclusions and further work 

In this paper we provide a lambda-calculus with records and a record-merge operator to describe classes, 
mixins and mixin-applications in object-oriented languages featuring an early binding of method calls. 
We demonstrate its potential by composing well typed programs in Java and C# that itself do not inher¬ 
ently support mixins. The delegation based approach in combination with subtyping turns out to be more 
flexible as well as powerful than inheritance and overloading. In future, we aim to develop a theory for 
automatically synthesizing code for mixin-applications using an approach introduced in 0. 
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